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Abstract 

The SARGE program Is a prototype of a program which la intended to be 
used as an adjunct to regular classroom work in freshman calculus. Using 
SARGE, students can type their step-by-step solution to an indefinite 
integration problem, and can have the correctness of their solutions deter- 
mined by the system. The syntax for these steps comes quite dose to normal 
mathematical notation, given the limitations of typewriter input. The 
method of solution is pretty much unrestricted as long as no mistakes are 
made along the way. If a mistake Is made, SARGE will catch it and yield an 
error message. The student may modify the incorrect step, or he may ask 
the program for advice on how the mistake arose by typing "help 11 . At present 
the program is weak in generating explanations for mistakes. Sometimes the 
'"help" mechanism will ]uat yield a response which will indicate the way in 
which the erroneous step can he corrected. In order to improve the explana- 
tion mechanism one would need a sophisticated analysis of studonts* solutions 
to homework or quiz problems. Experience with the behavior of students with 
SARGE, which is nil at present* should also help in accomplishing this goal. 

SARGE is available as SARGE SAVED in T302 2517. 



Introduction 

Our aim in this project was to use the programs available at M.I.T. 
in the area of algebraic manipulation in order to produce a sophisticated 
teaching program for freshman calculus students* As a matter of fact, we 
were not interested in teaching symbolic or indefinite integration as such, 
since the normal courses performed this function quite well. We were 
interested in a program which could be used to supplement regular instruc- 
tion with supervised practice sessions* Normally, human teaching assistants 
would be used for this purpose. Thus our goal can be said to be a simulation 
of the interaction of a student and a coaching assistant. In order to 
capture certain aspects of such an interaction two major design considerations 
were imposed. 

1) Freshman calculus students are not computer programmers. Therefore 
the communication with the teaching system should be as natural as possible. 

2) There should be no impediment to unusual solutions of a problem. 
Such unusual solutions Include ingenious solutions as well as solutions 
with superfluous or erroneous steps. A student must be capable of giving 
the complete answer at any step. This capability will guarantee that gifted 
students who can solve the problem In their heads will not be forced to give 
a full step-by-step solution of a problem- Likewise a student who makes a 
false attempt at solving a problem must be allowed to backtrack and attempt 
another path to a solution. 



We wish to distinguish between false attempts and Incorrect attempts* In 

Jx Z dx, 
the substitution y ■ x Is bad even though th* r«sutt of this substitution, i.e., 
pi -2/5 

is given correctly* in the same problem the substitution y » x is incorrect 
when it results in 



# 



y dy. 



The SARGE program meets Che above requirements fairly well. Below we 
shall describe tbc manner In which one communicates a solution to SARGE* 
Wo will also indicate how the system operates* Later wo shall criticize 
the present version of the system and present suggestions for its improvement. 

Communicating with SARflE 

We will present the syntax of the Language that the student must use to 
communicate a solution to SARGE through an interaction between an imaginary 
student and the program (see figure 1). Let us suppose that the problem 
to be integrated is 

j (x + 1) <x + 2) dx. 
This problem would be typed by SARGE as follows: 

PROBLEM INT (X +1) <X + 2) DX 

The above line is representative of the statements In SARGE's language. All 
statements in the language have the following formt 

Line-number command (command argument) (expression) 

(The Utter two components of a statement have been parenthesized to indicate 
that they need not be present in each statement,) 

The first component of an input line Is an unsigned integer which Is 
taken as a line number. Line numbers are chosen by the student, except 
that the problem is always presented as line 0* Line numbers should bo 
distinct, and are used to identify steps in a solution. 

Commands are used to indicate how the expression arose In the solution 
process. The current sot of commands is PROBLEM, 5UBST, TRANS F» ASS , 
PARTOF, and RFTURNTO. The PROBLB* command is used only in defining a new 
problem, and may not be used Later on in the solution. The PROULEM comma r 1 
has no command argument. Thus the next component of the line is taken to 



be an expression* Line indicates some Interesting features of the 
expression syntax. For example, concatenation implies multiplication except 
when numbers are involved. This is the standard mathematical convention, 
and it forces the convention that all variables are single characters. 
Furthermore, an attempt was made to keep the usual syntax of the indefinite 
integral. Thus 

f{x) dx becomes int f(x) dx. 
In line 1 the command used is TRANS F. 

1 transf int x§2 + 3x +2 dx 

This command is used when the expression is derived from the previous line 
by An equivalence preserving transformation. Line i is derivod from line 
by &n expanalon. Note that no justification need be given for the 
equivalence* 

In line 1 we note that the dollar sign signifies exponentiation. The 
convention regarding the dollar sign is that if the exponent or base are 
single syntactic units (unsigned numbers or alphabetic characters) then na 
parentheses are required. If more complex bases or exponents are used 
(e.g., x+l), then parentheses must be used. This common ly-used convention 
applies also to the slash which signifies division. 

Ihe first statement which has the line number 2 is a transformation 
which involves certain identities regarding the integration operator. 

2 transf lot x$2dx + int 2x dx + int 2dx 

5ARGE is aware of these linearity identities and moreover recognizes 
an error in transcription. This is noted by SARGE's next response. 
AN ERROR OCCURRED AFTER LINE 1 WAS ANALYZED 

An examination of figure I will Indicate that SARGE's response up to 
now was a number which equaled the line number of the previous statement. 
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Ihis is called the slow mode of interaction. In the fast mode, SARGE will 
make no responses unless an error occur*. The normal mode Is slow* A change 
in node can be made by executing SUJW NIL or FAST NIL prior to working on a 
problem. FAST NIL will cause the mode to change to fast. 

After indicating that an error occurred the system anticipates a new 
set of key words. The keyword 'help 1 which is used in this case causes 
SARGE to examine a list which contains probable explanations for the error. 
Clearly the help mechanism should be used only as a lart resort by the 
student. Frequently SARGE has no reasonable idea to transmit to the user , 
in which case the response is 

SORRY, NO IDEA WHY ERROR OCCURRED. 
In the present situation it can Only offer the student a means for correcting 
his last step. It therefore types 

THE DIFFERENCE BETWEEN THE EXPECTED EXPRESSION AND YOURS IS 

X 

Other keywords which arc recognised following an error are 'quit 1 and 
'oval*. The quit mechanism allows the user to stop working on the current 
problem. The eval mechanism, used during the debu&ftinft of SARGE, allows one to 
execute any LISP function available in the system. Any line which follows 
an error and which does not begin with these keywords is Ignored. 

The second occurrence of line 2 indicates that the student 

2 trans f lnt x$ 2dx + int >dx + int 2dx 

has accepted the advice offerred by SARGE. In Line 3 the user is preparing to tucklc 
a subproblem of Line 2. Ho identifies the part of the expression lie wants 
to work on next with the PARTOF command. The coraaand argument here is a line 
number. 

3 partof 2 int x$2dx 



In line 4 the user is attempting co make a substitution on the 

subproblem selected in the previous line. The command 

4 subst f*Bt$2 v int y dy 

argument is an equation relating the new variable to the old one* This 

operation is restricted to having only one occurrence of the new variable 

{'y' in this case). For syntactic purposes a comma must follow this equation 

and precede the expression of the integral* As it turns out the result of 

the substitution is erroneous. SARGE now prints its standard error commenc* 

A call for help at this point yields a very appropriate reply. 

IN YOUR SUBSTITUTION YOU FORGOT TO DIVIDE 
BY THE DERIVATIVE OF THE TRANSFORMATION 

The second line 4 shows a correction 

4 sub, y-xS2, tnt 0.5 ySO.S dy 
of this error. He note a new syntactic device -- a comma following one or 
more of the left-most characters in a cotmnand can be used to abbreviate the 
command name* 

Line 5 was included here as an example of the RETURNTO mechanism. This 
mechanism allows a student who is frustrated in his current attempt at a 
solution to continue from a previous Line. 

Our student is determined to solve this problem in line 3 (which 
admittedly Is a trivial problem) by a substitution. This analysis explains 
the first line 6. 

6 subst y=x$(l/2), int y? 
The qucBtion-marfc is q CTSS device for deleting the input line. Actually 
an empty line is transmitted to SARGE and is ignored. In some situations a 
student may wish to stop processing of a solution in a more drastic fashion. 
This would occur if the student typed a number of lines in fast mode and 
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recognized an error in them before the system had a chance to analyse tho 
solution. An interrupt from the console would causa an error* and the message 

Iran SARGK will indicate tho extent to which it analyzed tho solution. 
The second line 6 shows that our poor student has finally seen the 

light and recognized the solution of the subproble^n. 

6 ans 3 xS3/3 

The ANS command has aa its command argument the line number of the subprobltiro 
whose Integral appears as the expression* 

We are now approaching the end of the interaction- In lino 7 we go 
back to line 2 to pick up another subproblem, 

7 partof 2 3 Int x dx 

Line 8 contains the integral of that subproblem. 

8 an* 7 3/2 x$Z 

Line 9 claims to be the solution to the original problem (line 0), which it 
Is Indeed. Note that ' line (n) ' causes the expression of line n to be sub- 
stituted in its position in the expression. 

We give in figures 2 and 3 two further examples of interactions with 
SARGE. No new linguistic features are introduced except for the use of 
trigonometric functions in the obvious manner- 



How does SARGH work? 

From a certain point of view the SARGS program Is quite trivial. It took 
us only two weeks to got most of the system running and in partially debugged 
shape. However the size of the program is quite Urge (about 7000 compiled 
instructions and an equivalent of 3000 interpreted ones in the usual 32K 
LZSF 1.5 system on CTSS). As we indicated earlier we intended to rely on 
the large store of available LISP programs in the area of algebraic 
manipulation. The most Important of these programs, for our purposes, was 
William Martin's equivalence matching routines (see 1, Chapter 4). This 
program determines whether two expressions are equivalent by a very clever use 
of hash coding. Martin's program is deadly in recognizing equivalence of 
rational functions or rational function of trigonometric functions. For 
example, this program allows SAftGE to recognize the equivalence of 1/2 &ln{2x) 
and sin(x) cos (x) in figure 2. This routine is currently weak in recognizing 
equivalence of expressions involving square-roots. One could, however, design 
special routines which would recognize such situations and overccene them in 
many instances. Should the matching routine fall to recognize an equivalence, 
then SARGB would claim that an error was made when, in fact, none was. 
Currently there exists no machinery which allows the user to argue against 
the decisions of SARGE. Though errors of this nature occur very rarely. It 
would be useful to give the user the capability of overcoming the decisions 

of the system. 

Another one of Martin's programs is used for parsing the input expression 
into prefix notation. The input line la read, character by character, by one 
of our programs which transforms the expression somewhat before giving it to 
Martin's parsing routine (e.g., special attention must be paid to the intcgr.il 
sign syntax). The result of the parse of 
int 2x+l dx 



is 

(integral (plus (times 2 x) 1) x) . 
If the expression is a sum of integrals then tt Is transformed into an integral 
of a sum. Hence line 2 of figure L is stored internally exactly as line 1 is. 
This transformation simplifies the coding. It should be noted that the system 
currently requires that an expression reduce either to a simple integral or to 
an expression involving no integrals. Hence integration-by-part* Ls an illegal 
transformation. The changes necessary to overcome this restriction can be 
easily nadti 

It should be clear that, in addition to the routines mentioned above, we 
require a symbolic differentiation program (used, [or example. In determining 
the correctness of a proposed answer), a simplification program (an important 
component of the substitution checking mechanism), and a "solve" program 
(also needed in sufceti tut ions)* These routines were stolen from our work on 
S1N{2), the infamous symbolic integrator. For the operation of these routines 
we required the SCKATCKEN pattern matching program. The SCHATCHEH language 
allows one to express concepts like "a quadratic in x" quit* concisely- We 
hsve not made much use of SCHATCHEN in the current SARGE system, although we 
expect that an improved version will find its presence quite useful. 

The main routine in SARGE, also called SARGE, is a fairly straight- 
forward interpreter of the input lines. Whenever an error occurs a check 1ft 
made to determine whether any rules exist about how to treat the input line. 
If rules exist and the input line fits the expected error condition, a note 
is made in a location called 'help'- Otherwise 'help' is unchanged. 

The main program is executed interpretively during the operation of the 
syetec because there is no space available in which to compile it and because 
It changes so drastically. The three interactions described in figures 1-3 



each require about twenty seconds of execution time and a similar amount of 
swapping time. Hence the answer to the question posed in the beginning of 
this section is -- SARGE works slowly. It is likely that a three-fold 
improvement in speed could be had if the entire system were compiled. 

There are, at present, two nodes in which a problem la proposed to the 
user. In the slave mode the program proposes one of a set of built-in 
problems. This mode is activated by typing 'SLAVE NIL 1 . In the master mode > 
the usor decides the problem on which he wants to work. This mode is activated 
by typing 'MASTER NIL 1 . In either case, control reverts to LIS? following an 
interact ion * 



Critique and Fbture Directions 

Below we shall consider some criticism* of the present SARGC system. 

1) The syntax of SARGE is one dimensional. It should be two dimensional. 
The use of a typewriter as th« input medium hinders a natural interaction with 
the computer. A RAND Tablet or some similar device is clearly called for. 
Programs which parse mathematical expressions written on a RAND Tablet have 
been designed by Anderson (3) and Martin (4). Such programs should be 
operational soon. However, there are some difficulties with the use of a 
RAND Tablet for this application. The typewriter input forces on the user a 
line-by-line format. Given the freedom possible with a RAND Tablet, the user 
is likely to generate much input which does not conform to SARGE's syntax 
(a.g. i side calculations for the determination of derivatives, doodles, etc.). 
This will make the parsing problem a good deal more complicated. Furthermore 

o user station vhich includes a scope and a RAND Tablet is a good 

deal more expensive and consumes more computer time than a station which 

simply haa a typewriter console* 

2) The system is too inefficient for practical use by a large body of 
students. This is principally due to the scavenger approach we adopted in 
designing the system. A specially designed version should run substantially 
faster- 

3) The error diagnosing capability of the system is not very powerful. 
What appears to be necessary here is a sophisticated analysis of the mistakes 
that students frequently make in integration problems* Such research could 
proceed in several stages. At one stage one might determine a set of commonly 
mada errors (such as the error in substitution of figures 1 and 3). These 
errors would be known to the program and it would determine when such errors 
account for the input expression. In a second step, one would analyze Lhe 
interactions students have with such a program. This analysis could be used 



to Improve the diagnostic capability. Finally one would want the program to 
build models of the behavior of each student so that the problem which arc 
posed and the diagnosis given by the system becomes individualized. These 
are non-trivial objectives which face many difficulties. One obvious source 
of difficulty is Che intelligent student who will try to 'program 1 the system 
in order to see what it will do under certain situations. The system should 
be clover enough to recognize when it is being "hacked*. 

The current error comments are not At all subtle. It would be 
preferable if one could proceed in stages by using hints at first, if a script 
were available to the program, then such hints could be built into the 
script for each problem. We have tried to avoid the script-based approach 
as much as possible. We have depended on the knowledge that the program has 
of the material to help it in diagnoses. Such knowledge Is usually lacking in 
script-based teaching systems. However, one way of extending the present 
system would involve the use of scripts. For example, one could Include in 
a script several methods of solution and several common mistake* made on 
each particular problem. In order to keep the system as flexible as possible 
one would have to determine how far the student has progressed in following a 
given solution method, and how to return to such built-in solutions from the 
solution developed by the student. This problem, too, is hardly trivial. 

In sunmary, it would seem to us that a marriage of the script-based 
approach and the 'knowledge-based' approach is preferable to either approach. 
However there are difficult problems in making auch a marriage a viable 
proposition. 
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slave nil 
PROBLEM OTT (X+l)(X+2) DX 


1 trtnif int x$2 +3x + 2 dx 

1 

2 trans f int x$2 dx + int 2x dx + int2dx 

AN ERROR OCCURRED AFTER LINE 1 WAS ANALYZED 
help 

THE DIFFERENCE BETWEEH THE EXPECTED EXPRESSION AND YOURS TS 

X 
1 

2 trans f int x§2 dx + lnt 3x dx + int 2 dx 

2 

3 partof 2 lnt x$2 dx 
3 

4 aubst y*x$2, int y dy 

AN ERROR OCCURRED AFTER LINE 3 WAS ANALYZED 
help 



computer 
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computer 


OF THE TRANSFORMATION 


computer 


3 


user 


4 subst y*xS2, int 0.5 y$Q.5 dy 


computer 


4 


user 


5 ret ,3 


computer 


5 


user 


6 subst y=x$(l/2), int y? 


user 


6 ans 3 x$3/3 


computer 


6 


user 


7 partof 2 int 3 x dx 


computer 


7 


user 


8 ans? 1,5x52 


computer 


8 


user 


9 ans line (6) 4line(8) +2x 


computer 


CORRECT 



Figure I 



computer PROBLEM INT SIN<X)COS(X) DX 

computer 

user 1 transf lnt 0.5sin(2x)dx 

computer 1 

user 2 trans F 0\5 Lnt sin(2x) dx 

computer 2 

user 3 subst y=h, 1/2 int 1/2 sin(y) dy 

computer 3 

user 4 *ns3 (1/2) (1/2) (-cos (y)) 

computer 4 

user 5 ansO *l/4cos(2x) ( sin(x)$2 + cos(x)$2 ) 

computer CORRECT 



Ftguto 2 



user 


fast nil 


computer 


KIL 


user 


master nil 


computer 


PROBLEM 


user 


int e$(2x)/< 1 + *$<4x» <** 


user 


1 subst y-e$x, int yS2/0+yS*) dy 


computer 


Atf ERROR OCCURRED AFTER LIKE WAS AKALY 


user 


oh, ye* 


user 


1 subst y=eSx> int y/(l+y$4) dy 


user 


2 sub, z=y$2, int 0.5/<l+z$2) dr 


user 


3 ans 2 1/2 arctan<z) 


user 


ft an* 1/2 arctan<(cSx)S2) 


computer 


CORRECT 



Figure 3 
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